> > I'm certainly no security expert, but I had a fairly simple idea > for fixing the sequence number guessing vulnerability. Hopefully > someone can tell me whether it's worthless or not. Hunting season's > open -- shoot it down at will. :-) > > When OS boots up, grab lots of entropy and use MD5 to hash it > into a 32 bit seed; initialize tcp_iss with it. Now let the > kernel do its normal "increment tcp_iss a little for every new > connection and every couple of clock ticks" schtick as always. This is a good start... > I've only got one novel idea: instead of using tcp_iss directly > for the SYN everytime a new TCP/IP connection is opened, send > MD5(tcp_iss) [or maybe MD5(tcp_iss, time(NULL), ...)]. not bad either...but rather than just when it is opened, perhaps something a bit different but very similar... > This implements a cryptographically strong random number generator > for the sequence numbers; then attackers would have to invert > MD5 to predict sequence numbers. MD5 is quite fast (is it fast > enough?) and is completely exportable. Code for MD5 is available > for anonymous ftp on ripem.msu.edu /pub/crypt/other/md5.zip. > > To nitpick, tcp_iss should be a full 64 bit (or even larger :-) > data type; this is easy enough to change in the kernel: (right?) No. For the patch to be most useful, it should work with minimal alteration to .o's (I've learnt this) unless you're Sun/DEC, etc. Even then, most people will be reluctant to make these sort of changes unless they're confident about what they're doing. [...] > So, am I missing some important kernel feature which shoots this > all down? Or is this actually a worthwhile technique? [If it > is worthwhile, it seems like it'd be pretty easy to code -- but > I have no experience at kernel programming, so I haven't done it > myself. <sigh>] If you don't interfere with the generation of tcp_iss at the *right* time (and remember, for some stupid reason to do with 4.2BSD, you're limited to 31 bits) the kernel will hapily make tcp_iss 0 for you, regardless of what your increments were in and what it started out at. It would seem that the easiest way to "hijack" the generation of the tcp_iss variable in the kernel is to mess with the table in in_proto.c (which is shipped with all SunOS 4.1.x and is compiled when you generate your own kernel). Indeed, rather than use that program to mess with ip_output.o and insert a wrapper, you can simply put your wrapper into the table here and voila! If, for example, we used the above idea, it should be trivial to write a wrapper for tcp_input which set tcp_iss to whatever only when it was a pure "SYN" packet coming in. How hard is that ? MD5(foo) tcp_seq foo; { ... return bar; } tcp_input_wrap(m) struct mbuf *m; { struct ip *ip; struct tcphdr *tcp; ip = mtod(m, struct ip *); tcp = (struct tcphdr *)((char *)ip + ip->ip_hl << 2); if (tcp->th_flags == TH_SYN) tcp_iss = MD5(tcp_iss); return tcp_input(m); } and in in_proto.c, we replace tcp_input with tcp_input_wrap in the table for SOCK_STREAM. The rest is academic... darren